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Carrying Protocol Independent Multicast - Sparse Mode (PIM-SM) 
in Any-Source Multicast (ASM) Mode Trees over Multipoint LDP (mLDP) 


Abstract 


When IP multicast trees created by Protocol Independent Multicast - 
Sparse Mode (PIM-SM) in Any-Source Multicast (ASM) mode need to pass 
through an MPLS domain, it may be desirable to map such trees to 
Point-to-Multipoint Label Switched Paths (P2MP LSPs). This document 
describes how to accomplish this in the case where such P2MP LSPs are 
established using Label Distribution Protocol (LDP) Extensions for 
P2MP and Multipoint-to-Multipoint LSPs: Multipoint LDP (mLDP). 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7442. 
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Copyright Notice 


Copyright (c) 2015 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 


carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 


include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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Les 


Introduction 


[RFC6826] describes how to map Point-to-Multipoint Label Switched 
Paths (P2MP LSPs) created by mLDP [RFC6388] to multicast trees 
created by Protocol Independent Multicast - Sparse Mode (PIM-SM) in 
Source-Specific Multicast (SSM) mode [RFC4607]. This document 
describes how to map mLDP P2MP trees to multicast trees created by 
PIM-SM in Any-Source Multicast (ASM) mode. It describes two possible 
mechanisms for doing this. 


The first mechanism, described in Section 2, is OPTIONAL for 
implementations, but the second mechanism, described in Section 3, is 
REQUIRED for all implementations claiming conformance to this 
specification. 


Note that from a deployment point of view these two mechanisms are 
mutually exclusive. That is, on the same network one could deploy 
either one of the mechanisms, but not both. 


The reader of this document is expected to be familiar with PIM-SM 
[RFC4601] and mLDP [RFC6388]. 


This document relies on the procedures in [RFC6826] to support source 
trees. For example, following these procedures a Label Switching 
Router (LSR) may initiate an mLDP Label Map with the Transit 
IPv4/IPv6 Source TLV for (S,G) when receiving a PIM (S,G) Join. 


This document uses BGP Source Active auto-discovery routes, as 
defined in [RFC6514]. For the sake of brevity in the rest of this 
document, we’ll refer to these routes as just "Source Active 
auto-discovery routes". 


Consider a deployment scenario where the service provider has 
provisioned the network in such a way that the Rendezvous Point (RP) 
for a particular ASM group G is always between the receivers and the 
sources. If the network is provisioned in this manner, the ingress 
Provider Edge (PE) for (S,G) is always the same as the ingress PE for 
the RP, and thus the Source Active auto-discovery (A-D) routes are 


never needed. If it is known a priori that the network is 
provisioned in this manner, mLDP in-band signaling can be supported 
using a different set of procedures, as specified in [RFC7438]. A 


service provider will provision the PE routers to use either the 
procedures in [RFC7438] or those described in this document. 
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Like [RFC6826], each IP multicast tree is mapped one-to-one to a P2MP 
LSP in the MPLS network. This type of service works well if the 
number of LSPs that are created is under the control of the MPLS 
network operator, or if the number of LSPs for a particular service 
is known to be limited. 


It is to be noted that the existing BGP Multicast VPN (MVPN) 
procedures [RFC6514] can be used to map Internet IP multicast trees 
to P2MP LSPs. These procedures would accomplish this for IP 
multicast trees created by PIM-SM in SSM mode, as well as for IP 
multicast trees created by PIM-SM in ASM mode. Furthermore, these 
procedures would also support the ability to aggregate multiple IP 
multicast trees to one P2MP LSP in the MPLS network. The details of 
this particular approach are out of scope for this document. 


This document assumes that a given LSR may have some interfaces that 
are IP multicast capable, while other interfaces would be MPLS 
capable. 


1.1. Specification of Requirements 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in RFC 2119 [RFC2119]. 


2. Mechanism 1 - Non-transitive Mapping of IP Multicast Shared Trees 


This mechanism does not transit IP multicast shared trees over the 
MPLS network. Therefore, when an LSR creates (*,G) state (as a 
result of receiving PIM messages on one of its IP multicast 
interfaces), the LSR does not propagate this state in mLDP. 


2.1. Originating Source Active Auto-discovery Routes (Mechanism 1) 
Whenever (as a result of receiving either PIM Register or Multicast 


Source Discovery Protocol (MSDP) messages) an RP discovers a new 
multicast source, the RP SHOULD originate a Source Active 


auto-discovery route. The route carries a single MCAST-VPN Network 
Layer Reachability Information (NLRI) [RFC6514], constructed as 
follows: 


+ The Route Distinguisher (RD) in this NLRI is set to 0. 
+ The Multicast Source field is set to S. This could be either an 


IPv4 or an IPv6 address. The Multicast Source Length field is set 
appropriately to reflect the address type. 
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+ The Multicast Group field is set to G. This could be either an 
IPv4 or an IPv6 address. The Multicast Group Length field is set 
appropriately to reflect this address type. 


To constrain distribution of the Source Active auto-discovery route 
to the Autonomous System (AS) of the advertising RP, this route 
SHOULD carry the NO_EXPORT Community ([RFC1997]). 


Using the normal BGP procedures, the Source Active auto-discovery 
route is propagated to all other LSRs within the AS. 


Whenever the RP discovers that the source is no longer active, the RP 
MUST withdraw the Source Active auto-discovery route if such a route 
was previously advertised by the RP. 


2.2. Receiving Source Active Auto-discovery Routes by LSR 


Consider an LSR that has some of its interfaces capable of IP 
multicast and some capable of MPLS multicast. 


When, as a result of receiving PIM messages on one of its IP 
multicast interfaces, an LSR creates in its Tree Information Base 
(TIB) a new (*,G) entry with a non-empty outgoing interface list that 
contains one or more IP multicast interfaces, the LSR MUST check to 
see if it has any Source Active auto-discovery routes for that G. If 
there is such a route, S of that route is reachable via an MPLS 
interface, and the LSR does not have (S,G) state in its TIB for (S,G) 
carried in the route, then the LSR originates the mLDP Label Map with 
the Transit IPv4/IPv6 Source TLV carrying (S,G), as specified in 
[RFC6826]. 


When an LSR receives a new Source Active auto-discovery route, the 
LSR MUST check to see if its TIB contains a (*,G) entry with the same 
G as that carried in the Source Active auto-discovery route. If such 
an entry is found, S is reachable via an MPLS interface, and the LSR 
does not have (S,G) state in its TIB for (S,G) carried in the route, 
then the LSR originates an mLDP Label Map with the Transit IPv4/IPv6 
Source TLV carrying (S,G), as specified in [RFC6826]. 


2.3. Handling (S,G,RPT-bit) State 
The creation and deletion of (S,G,RPT-bit) PIM state ([RFC4601]) on 
an LSR that resulted from receiving PIM messages on one of its IP 


multicast interfaces do not result in any mLDP and/or BGP actions by 
the LSR. 
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3; 


3. 


Mechanism 2 - Transitive Mapping of IP Multicast Shared Trees 


This mechanism enables transit of IP multicast shared trees over the 
MPLS network. Therefore, when an LSR creates (*,G) state as a result 
of receiving PIM messages on one of its IP multicast interfaces, the 
LSR propagates this state in mLDP, as described below. 


Note that in the deployment scenarios where, for a given G, none of 
the PEs originate an (S,G) mLDP Label Map with the Transit IPv4/IPv6 
Source TLV, no Source Active auto-discovery routes will be used. One 
other scenario where no Source Active auto-discovery routes will be 
used is described in Section 3.2 ("Originating Source Active 
Auto-discovery Routes (Mechanism 2)"). In all of these scenarios, 
the only part of Mechanism 2 that is used is the in-band signaling 
for IP Multicast Shared Trees, as described in the next section. 


1. In-Band Signaling for IP Multicast Shared Trees 


To provide support for in-band mLDP signaling of IP multicast shared 
trees, this document defines two new mLDP TLVs: the Transit IPv4 
Shared Tree TLV and the Transit IPv6 Shared Tree TLV. 


These two TLVs have exactly the same encoding/format as the IPv4/IPv6 
Source Tree TLVs defined in [RFC6826], except that instead of the 
Source field they have an RP field that carries the address of the 
RP, as follows: 


Transit IPv4 Shared Tree TLV: 


0 1 2 3 

0123456789012345°678°9012345 6789021 
Hof ofo fifi pit ipi pip p i pip g iti papi pig ipa gigi p igi gg iti ge gag 
Type | Length | RP 

—foFof offi Foti pi papi iti pipe g iti pip gigi papa p git igi gg iti gi get 


Length: 8 
RP: IPv4 RP address, 4 octets. 


Group: IPv4 multicast group address, 4 octets. 
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Transit IPv6 Shared Tree TLV: 


0 al 2 3 
O123 49°67 3 90-1 2.3.4-5 6 7° 8.9. 01 23.45.67 8 9 0 1 
Fat —tatatataota tata titan tatatata ta tata tatatatatatatatattatatatat-t 
| Type | Length | RP = 
Fat —tatHtata—ta tata tata ta tata ta ta tata tatatatatatatatatatatatat-t-Ft 
A | Group g 


Length: 32 

RP: IPv6 RP address, 16 octets. 

Group: IPv6 multicast group address, 16 octets. 
Procedures for in-band signaling for IP multicast shared trees with 
mLDP follow the same procedures as those for in-band signaling for 
IP multicast source trees, as specified in [RFC6826], except that 
while the latter signals (S,G) state using Transit IPv4/IPv6 Source 
TLVs, the former signals (*,G) state using Transit IPv4/IPv6 Shared 
Tree TLVs. 


3.2. Originating Source Active Auto-discovery Routes (Mechanism 2) 


Consider an LSR that has some of its interfaces capable of IP 
multicast and some capable of MPLS multicast. 


Whenever such an LSR creates an (S,G) state as a result of receiving 
an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for (S,G), 
the LSR MUST originate a Source Active auto-discovery route if all of 
the following are true: 

+ S is reachable via one of the IP-multicast-capable interfaces, 


+ the LSR determines that G is in the PIM-SM in ASM mode range, and 


+ the LSR does not have a (*,G) state with one of the IP-multicast- 
capable interfaces as an incoming interface (iif) for that state. 
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The route carries a single MCAST-VPN NLRI, constructed as follows: 
+ The RD in this NLRI is set to 0. 


+ The Multicast Source field is set to S. The Multicast Source 
Length field is set appropriately to reflect this address type. 


+ The Multicast Group field is set to G. The Multicast Group Length 
field is set appropriately to reflect this address type. 


To constrain distribution of the Source Active auto-discovery route 
to the AS of the advertising LSR, this route SHOULD carry the 
NO_EXPORT Community ([RFC1997]). 


Using the normal BGP procedures, the Source Active auto-discovery 
route is propagated to all other LSRs within the AS. 


Whenever the LSR receiving an mLDP Label Map with the Transit 
IPv4/IPv6 Source TLV for (S,G) deletes the (S,G) state that was 
previously created, the LSR that deletes the state MUST also withdraw 
the Source Active auto-discovery route, if such a route was 
advertised when the state was created. 


Note that whenever an LSR creates an (S,G) state as a result of 
receiving an mLDP Label Map with the Transit IPv4/IPv6 Source TLV for 
(S,G) with S reachable via one of the IP-multicast-capable 
interfaces, and the LSR already has a (*,G) state with the RP 
reachable via one of the IP-multicast-capable interfaces as a result 
of receiving an mLDP Label Map with the Transit IPv4/IPv6 Shared Tree 
TLV for (*,G), the LSR does not originate a Source Active 
auto-discovery route. 


3.3. Receiving Source Active Auto-discovery Routes 


Procedures for receiving Source Active auto-discovery routes are the 
same as those for Mechanism 1. 


3.4. Pruning Sources Off the Shared Tree 


If, after receiving a new Source Active auto-discovery route for 
(S,G), the LSR determines that (a) it has the (*,G) entry in its TIB, 
(b) the incoming interface (iif) list for that entry contains one of 
the IP interfaces, (c) at least one of the MPLS interfaces is in the 
outgoing interface (oif) list for that entry, and (d) the LSR does 
not originate an mLDP Label Mapping message for (S,G) with the 
Transit IPv4/IPv6 Source TLV, then the LSR MUST transition the 
(S,G,RPT-bit) downstream state to the Prune state. (Conceptually, 
the PIM state machine on the LSR will act "as if" it had received 
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Prune(S,G,rpt) on one of its MPLS interfaces, without actually having 
received one.) Depending on the (S,G,RPT-bit) state on the iif, this 
may result in the LSR using PIM procedures to prune S off the Shared 
(*,G) tree. 


The LSR MUST keep the (S,G,RPT-bit) downstream state machine in the 
Prune state for as long as (a) the outgoing interface (oif) list for 
(*,G) contains one of the MPLS interfaces, (b) the LSR has at least 
one Source Active auto-discovery route for (S,G), and (c) the LSR 
does not originate the mLDP Label Mapping message for (S,G) with the 
Transit IPv4/IPv6 Source TLV. Once one or more of these conditions 
become no longer valid, the LSR MUST transition the (S,G,RPT-bit) 
downstream state machine to the NoInfo state. 


Note that except for the scenario described in the first paragraph of 
this section, it is sufficient to rely solely on the PIM procedures 
on the LSR to ensure the correct behavior when pruning sources off 
the shared tree. 


3.5. More on Handling (S,G,RPT-bit) State 
The creation and deletion of (S,G,RPT-bit) state on an LSR that 
resulted from receiving PIM messages on one of its IP multicast 
interfaces do not result in any mLDP and/or BGP actions by the LSR. 


4. IANA Considerations 


IANA maintains a registry called "Label Distribution Protocol (LDP) 
Parameters" with a subregistry called "LDP MP Opaque Value Element 


basic type". IANA has allocated two new values, as follows: 
Value | Name | Reference 
SSS Ses +———— - HO 
a ISIE Transit IPv4 Shared Tree TLV [RFC7442] 
12 Transit IPv6 Shared Tree TLV [RFC7442] 
5. Security Considerations 


All of the security considerations for mLDP ([RFC6388]) apply here. 


From the security considerations point of view, the use of Shared 
Tree TLVs is no different than the use of Source TLVs [RFC6826]. 
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